There is currently a proliferation of organizational networked computing systems. Every type of organization, be it a commercial company, a university, a bank, a government agency or a hospital, heavily relies on one or more networks interconnecting multiple computing nodes. Failures of the networked computing system of an organization, or even of only a portion of it, might cause significant damage, up to completely shutting down all operations. Additionally, much of the data of the organization, if not all the data, exist somewhere on its networked computing system, including all confidential data comprising the “crown jewels” of the organization, such as prices, details of customers, purchase orders, employees' salaries, technical formulas, etc. Loss of such data or leaks of such data to unauthorized external entities might be disastrous for the organization.
Many organizational networks are connected to the Internet at least through one network node, and consequently may be subject to attacks by computer hackers or by hostile adversaries. Quite often the newspapers report incidents in which websites crashed, sensitive data was stolen, or service to customers was denied, where the failures were the results of hostile penetration into an organization's networked computing system.
Thus, many organizations invest a lot of efforts and costs in preventive means designed to protect their computing networks against potential threats. There are many defensive products offered in the market claiming to provide protection against one or more known modes of attack, and many organizations arm themselves to the teeth with multiple products of this kind.
However, it is difficult to tell how effective such products really are in achieving their stated goals of blocking hostile attacks, and consequently most CISOs (Computer Information Security Officers) will admit (maybe only off the record), that they don't really know how well they can withstand an attack from a given adversary. The only way to really know the strength and security of a system, is by trying to attack it as a real adversary would. This is known as red-teaming or penetration testing (pen testing, in short), and is a very common approach that is even required by regulation in some developed countries.
Penetration testing requires highly talented people to man the testing team. Those people should be familiar with each and every publicly known vulnerability and attacking method and should also have a very good familiarity with networking techniques and multiple operating systems implementations. Such people are hard to find and therefore many organizations give up establishing their own penetration testing teams and resort to hiring external expert consultants for carrying out that role (or completely give up penetration testing). However, external consultants are expensive and therefore are typically called in only for brief periods separated by long intervals in which no penetration testing is carried out. This makes the penetration testing ineffective, as vulnerabilities caused by new attacks, that appear almost daily, are discovered only months after becoming serious threats to the organization.
Additionally, even rich organizations that can afford hiring talented experts for in-house penetration testing teams do not achieve good protection. Testing for vulnerabilities of a large network containing many types of computers, operating systems, network routers and other devices is both a very complex and a very tedious process. The process is prone to human errors such as missing testing for certain threats or misinterpreting the damages of certain attacks. Additionally, because a process of full testing against all threats is quite long, the organization might again end with a too long discovery period after a new threat appears.
In view of the above deficiencies, automated penetration testing solutions were introduced in recent years by several vendors. These automated solutions reduce human involvement in the penetration testing process, or at least in some of its functions. Some of those systems automatically discover and report vulnerabilities of a networked system, potential damages that might be caused to the networked system, and potential trajectories of attack that may be employed by an attacker.
A penetration testing process involves at least the following main functions: (i) a reconnaissance function, (ii) an attack function, and (iii) a reporting function. The process may also include additional functions, for example a cleanup function that restores the tested networked system to its original state as it was before the test. In an automated penetration testing system, at least one of the above three functions is at least partially automated, and typically two or three of them are at least partially automated.
FIG. 1A (PRIOR ART) is a block diagram of code modules of a typical penetration testing system. FIG. 1B (PRIOR ART) is a related flow-chart.
FIG. 1A shows a typical prior art penetration testing system and its main functions, where in addition to the three main functions listed above there is also an optional cleanup function. Even though the figures show the reconnaissance, attack and reporting functions as operating in strictly sequential order, this is not necessarily so. For example, the attack and the reporting functions may operate in parallel or in an interleaved way, with the reporting function reporting first results obtained by the attack function, while the attack function is working on additional results. Similarly, the reconnaissance and the attack functions may operate in parallel or in an interleaved way, with the attack function detecting a vulnerability based on first data collected by the reconnaissance function, while the reconnaissance function is working on collecting additional data.
A reconnaissance function is the function within a penetration testing system that handles the collection of data about the tested networked system. The collected data may include internal data of network nodes, data about network traffic within the tested networked system, business intelligence data of the organization owning the tested networked system, etc. The functionality of a prior art reconnaissance function can be implemented, for example, by software executing in a server that is not one of the network nodes of the tested networked system, where the server probes the tested networked system for the purpose of collecting data about it.
An attack function is the function within a penetration testing system that handles the determination of whether security vulnerabilities exist in the tested networked system based on data collected by the reconnaissance function. The functionality of a prior art attack function can be implemented, for example, by software executing in a server that is not one of the nodes of the tested networked system, where the server attempts to attack the tested networked system for the purpose of verifying that it can be compromised.
A reporting function is the function within a penetration testing system that handles the reporting of results of the penetration testing system. The functionality of a prior art reporting function may be implemented, for example, by software executing in the same server that executes the functionality of the attack function, where the server reports the findings of the attack function to an administrator or a CISO of the tested networked system.
In FIG. 1A, code for the reconnaissance function, for the attack function, and for the reporting function are respectively labelled as 20, 30 and 40, and are each schematically illustrated as part of a penetration testing system code module (PTSCM) labelled as 10. The term ‘code’ is intended broadly and may include any combination of computer-executable code and computer-readable data which when read affects the output of execution of the code. The computer-executable code may be provided as any combination of human-readable code (e.g. in a scripting language such as Python), machine language code, assembler code and byte code, or in any form known in the art. Furthermore, the executable code may include any stored data (e.g. structured data) such as configuration files, XML files, and data residing in any type of database (e.g. a relational database, an object-database, etc.).
In one example and as shown in FIG. 1B, the reconnaissance function (performed in step S21 by execution of reconnaissance function code 20), the attack function (performed in step S31 by execution of attack function code 30) and the reporting function (performed in step S41 by execution of reporting function code 40) are executed in strictly sequential order so that first the reconnaissance function is performed by executing code 20 thereof, then the attack function is performed by executing code 30 thereof, and finally the reporting function is performed 40 by executing code thereof.
However, the skilled artisan will appreciate that this order is just one example, and is not a requirement. For example, the attack and the reporting functions may be performed in parallel or in an interleaved way, with the reporting function reporting first results obtained by the attack function, while the attack function is working on additional results.
Similarly, the reconnaissance and the attack functions may operate in parallel or in an interleaved way, with the attack function detecting a vulnerability based on first data collected by the reconnaissance function, while the reconnaissance function is working on collecting additional data.
FIG. 2 illustrates a prior art computing device 110 which may have any form-factor including but not limited to a laptop, a desktop, a mobile phone, a server, a tablet, or any other form factor. The computing device 110 in FIG. 2 includes (i) computer memory 160 which may store code 180; (ii) one or more processors 120 (e.g. central-processing-unit (CPU)) for executing code 180; (iii) one or more human-interface device(s) 140 (e.g. mouse, keyboard, touchscreen, gesture-detecting apparatus including a camera, etc.) or an interface (e.g. USB interface) to receive input from a human-interface device; (iv) a display device 130 (e.g. computer screen) or an interface (e.g. HDMI interface, USB interface) for exporting video to a display device and (v) a network interface 150 (e.g. a network card, or a wireless modem).
Memory 160 may include any combination of volatile (e.g. RAM) and non-volatile (e.g. ROM, flash, disk-drive) memory. Code 180 may include operating-system code—e.g. Windows®, Linux®, Android®, Mac-OS®.
Computing device 110 may include a user-interface for receiving input from a user (e.g. manual input, visual input, audio input, or input in any other form) and for visually displaying output. The user-interface (e.g. graphical user interface (GUI)) of computing device 110 may thus include the combination of HID device 140 or an interface thereof (i.e. in communication with an external HID device), display device 130 or an interface thereof (i.e. in communication with an external display device), and user-interface (UI) code stored in memory 160 and executed by one or more processor(s) 120. The user-interface may include one or more GUI widgets such as labels, buttons (e.g. radio buttons or check boxes), sliders, spinners, icons, windows, panels, text boxes, and the like.
In one example, a penetration testing system is the combination of (i) code 10 (e.g. including reconnaissance function code 20, attack function code 30, reporting function code 40, and optionally cleaning function code 50); and (ii) one or more computing devices 110 which execute the code 10. For example, a first computing device may execute a first portion of code 10 and a second computing device (e.g. in networked communication with the first computing device) may execute a second portion of code 10.
A prior art penetration testing system may be an actual attack penetration testing system that carries out penetration testing by accessing and attempting to attack the tested networked system. Such a system actually accesses the tested networked system during the test, and does not limit itself to simulation. This includes:
(i) collecting data by the reconnaissance function about the tested networked system and its components, by actively probing them. The probing is accomplished by sending queries or other messages to one or more network nodes of the tested networked system, and then deducing information about the tested networked system from the received responses or from network traffic triggered by the queries or the messages. The reconnaissance function may be fully implemented by software executing outside the tested networked system or by a combination of such software and software executing in one or more network nodes of the tested networked system that analyzes network traffic and network packets of the tested networked system.
(ii) verifying that the tested networked system can be compromised by actively attempting to compromise it and checking if it was indeed compromised. This implies that, as a side effect of executing an actual attack penetration test, the tested networked system might be actually compromised. Typically, prior art actual attack penetration testing systems include a function of cleanup and recovery activated at the end of the test, in which any compromising operation that was performed during the test is undone.
A prior art penetration testing system may be a simulated penetration testing system that carries out penetration testing while avoiding disturbance to the tested networked system and specifically avoiding any risk of compromising it. This implies, among other things, that (i) no installation of software agents of any kind on network nodes of the tested networked system is allowed, and (ii) whenever there is a need to verify that the tested networked system can be compromised by an operation or a sequence of operations, the verification is done by simulating the results of that operation or sequence of operations or by otherwise evaluating them, without taking the risk of actually compromising the tested networked system. Some prior art simulated penetration testing systems implement the simulation by duplicating all or parts of the hardware and software of the tested networked system. As such, when there is a need for verifying that an operation or a sequence of operations compromises the tested networked system, this is accomplished by attacking the duplicated system without risking the tested networked system. While this implementation achieves the goal of avoiding the risk of not compromising the tested networked system, it is highly expensive and is difficult to implement accurately, and is therefore rarely used.